In data storage systems it is desirable to enable internal copies of existing logical data units (LUs) for purposes of backup, possible restore in case of future data corruption, testing, etc. An early solution suggested copying entire LUs or “volumes,” so that two (or more) copies of the LU co-existed simultaneously in the system. In accordance with this approach, only the original LU is gradually modified as part of the operation of the storage system, whereas the copy is not modified, so that the state of the LU at the instant of establishing the copy could be restored. This approach requires that all the data in the original LU that has not been modified is kept twice in the system. Usually this duplicate data takes up large amounts of storage space. Moreover, implementing this approach involves a considerable investment of CPU resources that are required to enable copying all the data from the source to the target.
As a development of the above technique, the use of snapshots has been suggested. A snapshot is usually implemented by using markers or pointers. The snapshot is a virtual copy of a storage unit as it existed at the time of establishing the snapshot. In accordance with one implementation of snapshots known as “copy-on-write,” snapshots are characterized by the ability to maintain a single copy of source data that has not been modified, whereas, for modified data, two portions of data are kept: one for the original data being part of the snapshot and a second for the modified data. In accordance with one implementation of snapshots, unmodified data is associated with two pointers, one for the source storage unit and one for the snapshot, whereas for data that was modified, a pointer to the original data is added to the snapshot and the same pointer may be replaced at the source storage unit with a pointer to the modified data.
For storing the data created as part of the snapshot process, storage resources on a physical storage device, such as a disk, are allocated, typically in advance. Since data storage systems are dynamic, with time, the amount of data that needs to be stored as part of the snapshot activity accumulates, and increasing amounts of storage resources are used for storing the data. This and more, in many data storage systems where several volumes exist, typically for each volume several snapshots are created and the amount of data that needs to be stored grows with each snapshot. If too little storage resources are allocated for storing data as part of the snapshot activity, there is a risk of depleting the storage resources very quickly. On the other hand, if large amounts of storage resources are allocated for the storage activity, a snapshot solution becomes less attractive and less efficient, because you the amount of space being saved spared is less significant.
It has been suggested to create groups of volumes for which a shared pool of storage resources will be allocated for storing data associated with snapshots established on each volume group. Such a pool of storage resources that are allocated for storing data associated with snapshots established on a volume group is known as “a snapshot pool.”
Current storage snapshot methodologies and corresponding equipment do not suggest managing a snapshot storage pool, particularly by enabling an action that is effective for managing the snapshot storage pool based upon a predefined criterion corresponding to a ratio between a current amount of storage used for storing snapshots in the pool and a total storage capacity defined for the pool.